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REMARKS 

The amendment of claim 1 serves to clarify the invention and is not in response to the 
rejection of claim 1. 

The Examiner objected to claim 20. In response, Applicants have amended claim 20 to 
clarify the invention in accordance with the Examiner's suggestions. 

The Examiner rejected claims 1-5, 7-13, 15, and 17-18 under 35 U.S.C. §102(e) as 
allegedly being anticipated by Movshovich ct al. (US 6,434,170). 

The Examiner rejected claims 6, 14, 16, and 19-20 under 35 U.S.C. §103(a) as allegedly 
being unpatentable over Movshovich ct al. (US 6,434,170) in further view of Temple ct al. (US 
2003/0147430). 

Applicants respectfully traverse the § 102(e) and § 103(a) rejections with the following 
arguments. 
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The Kxamincr rejected claims 1-5, 7-13, 15, and 17-18 under 35 U.S.C. § 102(e) as 
allegedly being anticipated by Movshovich et al. (US 6,434,170). 

gjfli nnfi 1-5 and 7-10 

Applicants respectfully contend that Movshovich does not anticipate claim 1, because 
Movshovich does not teach each and every feature of claim 1 ► 

For example, Movshovich docs not teach the feature; 'Hhc string comparator comparing 
transport stream data from the data unloader to at least a portion of a compare value filter and 
storing a destination address of the transport stream data when the compared transport stream 
data matches the at least a portion of the compare value filter". 

As a first exatnplc why Movshovich does not teach each and every feature of claim 1, 
Movshovich does not teach die feature: "the string comparator comparing transport stream data 
from the data unloader to at least a portion of a compare value filter" (emphasis added). 

The Examiner alleges that the following quote from Movshovich, col 9> lines 48-63 
teaches the preceding feature of claim 1 : " ..the counter value on path 3S4 represents an address 
index which can be used to address particular memory queues corresponding to information 
identified by its PID. The address index can be used by a processing unit to generate a physical 
memory address where the particular transport packet will ultimately be stored prior to 
transmission to decoding units. The use of the address index in the local header allows a 
destination location to be designated without the need to develop the complete address until it is 
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necessary to actually write the transport packet to its corresponding memory queue" 
(Movshovich 9:48-63)," 

Tn response, Applicants contend that Movshovich, col. 9, lines 48-63 does not teach the 
"comparing" operation required by the preceding feature of claim 1 . In fact, Movshovich, col. 9, 
lines 48-63 is totally unrelated to the preceding feature of claim 1. 

As a second example why Movshovich docs not teach each and every feature of claim 1, 
Movshovich does not teach the feature: "the string comparator ... storing a destination address 
of the transport stream data when the compared transport stream data matches the at least a 
portion of the compare value filter" (emphasis added). 

The Examiner alleges that the following quote from Movshovich, col. 9, lines 48-63 
teaches the preceding feature of claim 1 : "...the counter value on path 384 represents an address 
index which can be used to address particular memory queues corresponding to information 
identified by its PID. The address index can be used by a processing unit to generate a physical 
memory address where the parlicular transport packet will ultimately be stored prior to 
transmission to decoding units. The use of the address index in the local header allows a 
destination location to be designated without the need to develop the complete address until it is 
necessary to actually write the transport packet to its corresponding memory queue" 
(Movshovich 9;48-63y 

Applicants contend that Movshovich, col. 9, lines 48-63 discloses use of an address 
index, whereas the preceding feature of claim 1 requires storage of a destination address. Indeed, 
the preceding quote in Movshovich, col. 9, lines 48-63 makes it clear that is an address index, 
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rather than address, which is to be used ("The use of the address index in the local header allows 
a destination location to he designated without the need to develop the complete address until 
it is necessary to actually write the transport packet to its corresponding memory queue" 
(emphasis added)). 

Furthermore, while the preceding quote in Movshovich, col. 9, lines 48-63 states that the 
address index can be used to generate an address, Movshovich, col. 9, lines 48-63 docs not teach 
storing said address as required by the preceding feature of claim 1 > The address appears to be 
generated and used on the fly. Indeed, Movshovich would have no need to store said address, 
since after the transport packet is written to its corresponding memory queue, the address is not 
longer needed and therefore need not be stored. In any event, Movshovich most certainly does 
not disclose storing the address. 

Also, the preceding quote in Movshovich, col. 9, lines 48-63 docs not teach storing said 
address conditionally; i.e., "when the compared transport stream data matches the at least a 
portion of the compare value filter" as required by the preceding feature of claim 1. 

Based on the preceding arguments, Applicants respectfully maintain that Movshovich 
does not anticipate claim I, and that claim 1 is in condition for allowance. Since claims 2-5 and 
7-10 depend from claim 1, Applicants contend that claims 2-5 and 7-10 arc likewise in condition 
for allowance* 

Claims 1M 3. 15. and 17-18 

Applicants respectfully contend that Movshovich docs not anticipate claim 1 1, because 
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Movshovich docs not teach each and every feature of claim 1 1 . 

As a first example why Movshovich docs not teach each and every feature of claim 1 1, 
Movshovich does not teach the feature: a compare register, the compare register storing at 
least one compare value filter; ii) a masking register, the masking register designating at least 
a portion of the compare value filter" (emphasis added). 

In analyzing u a compare register, the compare register storing at least one compare value 
filter", the Examiner alleges that PID table of 32 P1D entries stored in RAM (as disclosed in 
Movshovich, col 7, lines 5S-61) represents the "at least one compare value filter 11 of claim 1 1, 
Therefore, in order for the Examiner's argument to be logically consistent, Movshovich must 
teach a masking register that designates at least a portion of the PID table of 32 PID entries 
stored in RAM, which Movshovich does not teach. 

In particular, the Examiner alleges that Movshovich, col. 8, line 64 - coh 9, line 24 
teaches the masking register of claim 1 1 as being represented by PID mask register 362 for 
obtaining only the relevant bits for the comparison. In response, Applicants contend that 
Movshovich, col. 8, line 64 - col. 9, line 24 docs not teach that PID mask register 362 designates at 
least a portion of the PID tabic of 32 PID entries stored in RAM, as required in order for the 
Examiner's argument to be logically consistent. 

As a second example why Movshovich does not teach each and every feature of claim U, 
Movshovich does not teach the feature: "wherein the string comparator compares the other 
transport stream data from the data unloadcr to the designated at least a portion of the compare 
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value filter" (emphasis added). 

The Examiner alleges that the following quote from Movshovich, col. 9, lines 48-63 
teaches the preceding feature of claim 1 1 : "-..the counter value on path 384 represents an address 
index which can be used to address particular memory queues corresponding to information 
identified by its PID. The address index can be used by a processing unit to generate a physical 
memory address where the particular transport packet will ultimately be stored prior to 
transmission to decoding units. The use of the address index in the local header allows a 
destination location to be designated without the need to develop the complete address until it is 
necessary to actually write the transport packet to its corresponding memory queue" 
(Movshovich 9:48-63)." 

In response, Applicants contend that Movshovich, col. 9, lines 48-63 does not teach the 
"comparing" operation required by the preceding feature of claim 11. In fact, Movshovich, col. 
9, lines 48-63 is totally unrelated to the preceding feature of claim 1 1 . 

Moreover, the Examiner has alleged that PID table of 32 PID entries stored in RAM 
represents the "at least one compare value filter" of claim 1 1, as discussed supra. Therefore, in 
order for the Examiner's argument to be logically consistent, Movshovich must teach that the 
string comparator compares the other transport stream data from the data unloadcr to the 
designated at least a portion of the PID table of 32 PID entries stored in RAM, which 
Movshovich docs not teach. 

As a third example why Movshovich does not teach each and every feature of claim 1 1, 
Movshovich docs not teach the feature: 4< wherein the string comparator ... stores a destination 
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address of the other transport stream data at the address register when the compared other 
transport stream data matches the designated at least a portion of the compare value filter" 
(emphasis added). 

The Examiner alleges that the following quote from Movshovich, col 9, lines 48-63 
teaches the preceding feature of claim 11: "...the counter value on path 384 represents an address 
index which can be used to address particular memory queues corresponding to information 
identified by its P1D. The address index can be used by a processing unit to generate a physical 
memory address where the particular transport packet will ultimately be stored prior to 
transmission to decoding units. The use of the address index in the local header allows a 
destination location to be designated without the need to develop the complete address until it is 
necessary to actually write the transport packet to its corresponding memory queue 11 
(Movshovich 9:48-63)/' 

Applicants contend that Movshovich, col. 9, lines 48-63 discloses use of an address 
index, whereas the preceding feature of claim 1 1 requires storage of a destination address, 
Indeed, the preceding quote in Movshovich, col. 9, lines 48-63 makes it clear that is an address 
index, rather than address, which is to be used ('The use of the address index in the local header 
allows a destination location to be designated without the need to develop the complete 
address until it is necessary to actually write the transport packet to its corresponding memory 
queue" (emphasis added)). 

Furthermore, while the preceding quote in Movshovich, col. 9, lines 48-63 states that the 
address index can be used to generate an address, Movshovich, col. 9, lines 48-63 does not teach 
storing said address as required by the preceding feature of claim 11 , The address appears to bo 
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generated and used on the fly. Indeed, Movshovich would have no need to store said address, 
since after the transport packet is written to its corresponding memory queue, the address is not 
longer needed and therefore need not be stotcd. In any event, Movshovich most certainly does 
not disclose storing the address. 

Also, the preceding quote in Movshovich, col. 9, lines 48-63 docs not teach storing said 
address conditionally; i.e., "when the compared transport stream data matches the at least a 
portion of the compare value filter" as required by the preceding feature of claim 1 1 . 

In addition, the Examiner has alleged that PID table of 32 PID entries stored in RAM 
represents tho "at least one compare value filter" of claim 1 1, as discussed supra. Therefore, in 
order for the Examiner's argument to be logically consistent, Movshovich must teach that the 
string comparator stores a destination address of the other transport stream data at the address 
register when the compared other transport stream data matches the designated at least a portion 
of the PID table of 32 PID entries stored in RAM, which Movshovich does not teach. 

As a fourth example why Movshovich docs not teach each and every feature of claim 1 1, 
Movshovich docs not teach the feature: "a packet buffer". 

The Examiner alleges that the following quote from Movshovich, col. 6, lines 45-65 
inherently teaches the packet buffer of claim 1 1 : "[generally, the packet framcr 302 performs 
packet framing and byte alignment, as well as synchronization detection. The packet framcr 302 
continuously searches for the MPEG synchronization bye in the header of the incoming transport 
data stream... The framer 302 forwards the data to the PID match unit 304". The Examiner 
argues that "it is inherent that the packet framer temporarily store incoming data for successful 
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detection of synchronization and forwarding o f data to PJD match unit" (emphasis added) 

In response, Applicants respectfully traverse the preceding inherency argument of the 
Examiner. In order for a fact to be inherently disclosed by a reference, the fact must necessarily 
and inevitably follow from what is actually disclosed in the reference. 

Therefore, in order for Movshovich to inherently disclose a packet buffer in the 
demultiplexer based on the Examiner's argument relating to the framcr 302, the Examiner must 
demonstrate that it is necessary and inevitable to have a paeket buffer in the demultiplexer in 
order to accomplish "successful detection of synchronization and forwarding of data to PID 
match unit". Applicants contend that it is not necessary and inevitable to temporarily store the 
packet data In a buffer lhat exists within the demultiplexer in order for the framcr 302 to perform 
its functionality. For example, it is possible to temporarily store the packet data in a buffer that 
exists outside of the demultiplexer and is yet accessible to the framer 302. As another example, 
the framer 302 could read the packet, parse the packet, analyze the parsed packet to perform the 
framer 302 functionality, reconstruct the packet from the parsed packet, wherein all further 
processing could be on the reconstructed packet rather than the original packet. 

As an illustration from the prior art as to why the alleged inherency does net exist, sec 
Temple (US 2003/0147430) [0042]: "Although tho demultiplexer is described above as storing 
the received data before determining the addresses of the appropriate MPEG-TS data, the data 
may simply be examined on-the-fly, in other words in real time, and the desired data fed to the 
output and the other data directed to decoders in the demultiplexer or discarded accordingly", 

Accordingly, Applicants assert that Movshovich does not inherently teach a packet buffer. 
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Based on the preceding arguments, Applicants respectfully maintain that Movshovfch 
does not anticipate claim 1 1, and that claim 1 1 is in condition for allowance. Since claims 12-13, 
15 and 17-18 depend from claim 1 1 , Applicants contend that claims 12-13, 15 and 17-1 S arc 
likewise in condition for allowance. 
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35 U.S . C. S103(a) 

The Examiner rejected claims 6, 14, 16, and 19-20 under 35 U.S.C. § 103(a) as altcgodly 
being unpatentable over Movshovich ct al. (US 6,434,170) in further view of Temple et al. (US 
2003/0147430). 

Claims 6 

Since claim 6 depends from claim 1, which Applicants have argued supra to not be 
unpatentable over Movshovich under 35 U.S.C. §102(2), Applicants maintain that claim 1 is 
likewise not unpatentable over Movshovich in view of Temple under 35 U.S.C. §1 03(a). 

Plaimw 14. 1 6. and 19 

Since claims 14, 16, and 19 depend from claim 11, which Applicants have argued supra 
to not be unpatentable over Jones under 35 U.S.C. §102(2), Applicants maintain that claims 14, 
16, and 1 9 arc likewise not unpatentable over Movshovich in view of Temple under 35 U.S.C. 
§ 103(a). 

Claim 2 0 

Applicants respectfully contend that claim 20 is not unpatentable over Movshovich in 
view of Temple, because Movshovich in view of Temple does not teach or suggest each and 

every feature of claim 20. 

As a first example why Movshovich in view of Temple docs not teach or suggest each 
and every feature of claim 20, Movshovich in viow of Temple does not teach or suggest the 
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feature: "I) a compare register, the compare register storing at least one compare value filter; 
ii) a masking register, the masking register designating at least a portion of the compare value 
filter" (emphasis added). 

In analyzing "a compare register, the compare register storing at least one compare value 
filter", the Examiner alleges that P1D table of 32 P1D entries stored in RAM (as disclosed in 
Movshovich, col. 7, lines 58-61) represents the "at least one compare value filter" of claim 20. 
Therefore, in order for the Examiner's argument to be logically consistent, Movshovich must 
teach or suggest a masking register that designates at least a portion of the P1D table of 32 PID 
entries stored in RAM, which Movshovich docs not teach or suggest, 

In particular, the Examiner alleges that Movshovich, col. 8, line 64 - col, 9, line 24 
teaches the masking register of claim 20 as being represented by PID mask register 362 for 
obtaining only the relevant bits for the comparison. In response, Applicants contend that 
Movshovich, col. 8, line 64 - col. 9, line 24 does not teach or suggest that PID mask register 362 
designates at least a portion of the PID table of 32 PID entries stored in RAM, as required in order 
for the Examiner' s argument to be logically consistent. 

As a second example why Movshovich in view of Temple docs not teach or suggest each 
and every feature of claim 20, Movshovich in view of Temple does not teach or suggest the 
feature: "wherein the string comparator compares system memory data from the data unloadcr to 
the designated at least a portion of the compare value filter " (emphasis added). 

The Examiner alleges that the following quote from Movshovich, col. 9, lines 48-63 
teaches the preceding feature of claim 20: "...the counter value on path 384 represents an address 
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index which can be used to address particular memory queues corresponding to information 
identified by its P1D. The address index can be used by a processing unit to generate a physical 
memory address where the particular transport packet will ultimately be stored prior to 
transmission to decoding units. The use of the address index in the local header allows a 
destination location to be designated without the need to develop the complete address until it is 
necessary to actually write the transport packet to its corresponding memory queue" 
(Movshovich 9:48-63)." 

Tn response, Applicants contend that Movshovich, col. 9, lines 48-63 docs not teach or 
suggest the "comparing" operation required by tho preceding feature o f claim 20. In fact, 
Movshovich, col. 9, lines 48-63 is totally unrelated to the preceding feature of claim 20, 

Moreover, the Examiner has alleged that PID table of 32 PlD entries stored in RAM 
represents the "at least one compare value filter" of claim 20, as discussed supra. Therefore, in 
order for the Examiner's argument to be logically consistent, Movshovich must teach or suggest 
that the string comparator compares the system memory data from the data unloadcr to the 
designated at least a portion of the PlD table of 32 PID entries stored in RAM, which 
Movshovich docs not teach or suggest. 

As a third example why Movshovich in view of Temple does not teach or suggest each 
and every feature of claim 20, Movshovich in view of Temple docs not teach or suggest the 
feature: "wherein the string comparator ... stores a destination address of the system memory 
data at the address register when the compared system memory data matches the designated at 
least a portion of the compare value niter" (emphasis added). 
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The Examiner alleges that the following quote from Movshovich, col. 9, lines 48-63 
teaches the preceding feature of claim 20: "...the counter value on path 384 represents an address 
index which can be used to address particular memory queues corresponding to information 
identified by its PID. The address index can be used by a processing unit to generate a physical 
memory address where the particular transport packet will ultimately bo stored prior to 
transmission to decoding units. The use of the address index in the local header allows a 
destination location to be designated without the need to develop the complete address until it is 
necessary to actually write the transport packet to its corresponding memory queue" 
(Movshovich 9:48-63)." 

Applicants contend that Movshovich, col. 9, lines 48-63 discloses use of an address 
index, whereas the preceding feature of claim 20 requires storage of a destination address. 
Indeed, the preceding quote in Movshovich, col. 9, lines 48-63 makes it clear that is an address 
index, rather than address, which is to be used ("The use o f the address index in the local header 
allows a destination location to be designated without the need to develop the complete 
address until it is necessary to actually write the transport packet to its corresponding memory 

queue" (emphasis added)). 

Furthermore, while the preceding quote in Movshovich, col. 9, lines 48-63 states that the 
address index can be used to generate an address, Movshovich, col. 9, lines 48-63 docs not teach 
or suggest storing said address as required by the preceding feature of claim 20. The address 
appears to be generated and used on the fly. Indeed, Movshovich would have no need to store 
said address, since after the transport packet is written to its corresponding memory queue, the 
address is not longer needed and therefore need not be stored. In any event, Movshovich most 
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certainly does not disclose storing the address. 

Also, the preceding quote in Movshovich, col. 9, lines 48-63 does not teach or suggest 
storing said address conditionally; i.e., "when the compared system memory data matches the at 
least a portion of the compare value filter" as required by the preceding feature of claim 20. 

In addition, the Examiner has alleged that PID table of 32 PID entries stored in RAM 
represents the "at least one compare value filter" of claim 20, as discussed supra. Therefore, in 
order for the Examiner's argument to be logically consistent, Movshovich must teach or suggest 
that the siring comparator stores a destination address of the system memory data at the address 
register when the compared system memory data matches the designated at least a portion of the 
PrD table of 32 PID entries stored in RAM, which Movshovich does not teach or suggest 

As a fourth example why Movshovich does not leach each and every fealurc of claim 1 1, 
Movshovich in view of Temple docs not teach or suggest the feature: "a packet buffer". 

'Hie Examiner alleges that the following quote from Movshovich, col. 6, lines 45-65 
inherently teaches the packet buffer of claim 1 1 : "[generally, the packet framcr 302 performs 
packet framing and byte alignment, as well as synchronization detection. The packet framcr 302 
continuously searches for the MPEG synchronization bye in the header of the incoming transport 
data stream... The framcr 302 forwards the data to the PID malch unit 304". The Examiner 
argues that "it is inherent that the packet framcr temporarily store incoming data for successful 
detection of synchronization and forwarding of data to PID match unit" (emphasis added). 

In response, Applicants respectfully traverse the preceding inherency argument of the 
Kxamincr. In order for a fact to be inherently disclosed by a reference, the fact must necessarily 

09/660,867 23 



PAGE 24/28 * RCVD AT 1/3/2005 11:16:38 AM [Eastern Standard Time] 1 SVR:USPTO-EFXRF-1/0 " DNIS:8729306 ' CSID: 1 DURATION (mm-s$):07-58 



JAN-03-05 MOH 1 1 : 42 AM 



FAX MO, 



P. 25 



and inevitably follow from what is actually disclosed in the reference. 

Therefore, in order for Movshovich to inherently disclose a packet buffer in Ihc 
demultiplexer based on the Examiner's argument relating to the framcr 302, tho Bxamincrinust 
demonstrate that it is necessary and inevitable to have a packet buffer in the demultiplexer in 
order to accomplish "successful detection of synchronization and forwarding of data to PID 
match unit". Applicants contend that it is not necessary and inevitable to temporarily store the 
packet data in a buffer that exists within the demultiplexer in order for the framcr 302 to perform 
its functionality. For example, it is possible to temporarily store the packet data in a buffer that 
exists outside of the demultiplexer and Is yet accessible to the framer 302. As another example, 
the framcr 302 could read the packet, parse the packet, analyze the parsed packet to perform the 
framcr 302 functionality, reconstruct the packet from the parsed packet, wherein all further 
processing could be on the reconstructed packet rather than the original packet. 

As an illustration from the prior art as to why the alleged inherency does not exist, see 
Temple (US 2003/0147430) [0042]: "Although the demultiplexer is described above as storing 
the recei ved data before determining the addresses of the appropriate MPEG-TS data, the data 
may simply be examined on-the-lly, in other words in real time, and the desired data fed to the 
output and the other data directed to decoders in the demultiplexer or discarded accordingly". 

Accordingly, Applicants assert that Movshovich does not inherently teach a packet buffer. 

Moreover, even if Movshovich docs inherently teach a packet buffer (which Movshovich 
doesn't), inherency cannot be used to reject a claim under 35 U.S.C, §. 103(a). Sec 
In reShetly, 566 F.2d 81, 86, 195 U.S.P.Q. 753, 756-57 (C.C.P.A. 1977) (reversing the Board's 
rejection of a claim based on alleged inherency under 35 U.S.C. 1 03 of a method to curb appetite, 
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and slating: "[t]ho inherency of an advantage and its obviousness are entirely different questions. 
That which may be inherent is not necessarily known. Obviousness cannot be predicated on what 
is unknown"). 

As a fifth example why Movshovich in view of Temple does not teach or suggest each 
and every feature of claim 20, Movshovich in view of Temple does not teach or suggest the 
feature: "the front end logic selectively receiving the MPEG-2 transport stream and the 
alternative transport stream". 

The Examiner argues: "However, the Movshovich et al. reference is silent as to 
processing non-mpeg streams. Now note the Temple et al. reference that discloses a 
demultiplexer for receiving MPEG type signals and ATM type signals (Temple [0009]). The 
claimed a bypassablc packet parser and bypassablc synchronizer is met by "where the signal 
received by a set top box is a narrowcast signal, the MPEG-2 TS demultiplexer receives from the 
ATM termination and data extraction unit, an MPEG-2 transport stream which contains data 
corresponding to the required video, audio etc signal only...thc MPEG-2 TS demultiplexer docs 
Hlllo more than simply pass the data from its input to its output" (Temple [0034]). Therefore, the 
examiner submits that it would have been obvious to one of ordinary skill in the art at the time 
the invention was made to modify the Movshovich MPEG-2 transport demultiplexer with packet 
framcr and synchronizer with the Temple et nl. bypass of demultiplexing system when receiving 
ATM type si gnals for the purpose of allowing a user to receive broadcast and narrow cast signals 
so that users may have more control over the data being transmitted (Temple [0024-0025]).". 
In response, Applicants respectively contend that the Examiner's modification of 
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Movshovich by the alleged teaching of Temple is not persuasive, because Temple teaches away 
from using the MPEG-2 TS demultiplexer as suggested by the Examiner. Temple [0034] and 
[0035] explains that such usage of the MPEG-2 TS demultiplexer is highly inefficient 

Instead, Temple [0036] - [0041] describes a more complex demultiplexer having an 
added ATM recovery section and a AAI- PDU SAR unit for recovering ATM PDU data. 

In addition, Temple [0027] teaches that a multiplexor capable of receiving both broadcast 
and narrowcast signals is directed to processing only a very specific format of both broadcast and 
natrowcast data, namely a format which meets the ISO standard of the MPEG-2 TS. 
Additionally, Temple [0029] explains that "in order to transmit the ATM cells over tho network 
without having overly complicated hardware, the ATM cells are further coded using the same 
format as the MPEG transport stream to provide a pseudo MPEG transport stream. This pscudo 
MPEG transport stream may be transmitted over the network along with the broadcast MPEG- 
TS". 

Based on Temple's disclosure, Applicants maintain that a modification of Movshovich by 
the preceding teaching of Temple would be too complex and require the signal data to be 
formatted too specifically to bo obvious. Indeed, an individual desirous of receiving both 
broadcast and narrowcast signals would find it obvious to use Temple's demultiplexer directly 
rather thai to use Movshovich's demultiplexer modified by Temple's disclosure. 

Based on the preceding arguments, Applicants respectfully maintain that claim 20 is not 
unpatentable over Movshovich in further view of Temple, and that claim 20 is in condition for 
allowance. 
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CO\CLUSlOiS 



Based on tlie preceding arguments, Applicants respectfully believe that all pending claims 
and the entire application meet the acceptance criteria for allowance and therefore request 
favorable action. If the Examiner believes that anything further would be helpful to place flic 
application in better condition for allowance, Applicants invites the Examiner to contact 
Applicants' representative at the telephone number listed below. The Director is hereby 
authorized to charge and/or credit Deposit Account No. 09*0457. 





Jack P. Friedman 
Registration No, 44,688 



Sclimciscr, Olscn & Watts 
3 Lear Jet Lane, Suite 201 
Latham, New York 121 10 
(518)220-1850 
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